Data transmission services practiced in recent years on the Internet are constituted not only by services of the conventional download transmission type but also by more and more services of the so-called streaming transmission type. Under the download transmission scheme, video or audio data is downloaded from a sender server to a receiver terminal before the data is reproduced by the latter. Because the download transmission scheme allows the data to be reproduced only after it has been fully downloaded, the scheme is not suited for long-hour or real-time reproduction of video data.
Under the streaming transmission scheme, by contrast, already-received data is reproduced by the receiver terminal even as more data is being transferred to it from the sender server. Its features enable the scheme to be adapted to such applications as Internet phone calls, teleconferences, and on-demand video delivery over the Internet.
One Internet technology applicable to the streaming transmission service is RTP (Real-time Transport Protocol) stipulated by IETF (Internet Engineering Task Force) RFC (Request for Comments) 1889.
FIG. 1 is a schematic view showing a typical structure of an RTP header of an RTP packet. As illustrated, the example in FIG. 1 includes: a version number that indicates the version of RTP, padding made up of bits for adjusting the packet size, extension bits that may be designated for function extensions, a counter that indicates the number of senders involved in real-time transfer, a marker bit that indicates a data boundary, a payload type that indicates the encoding type, a sequence number that indicates the sequence of this RTC packet, a time stamp that indicates the time at which the RTP packet was transmitted, a synchronizing source identifier that identifies the initial sender of the message, and a contributing source identifier that identifies the sender having prepared a group of packets included in the message.
Attaching the time stamp to each packet enables the sender and the receiver to grasp their temporal relations during RTP-based data transfer. This helps minimize transmission irregularities of packets such as delay fluctuations (jitters), so that packetized data may be reproduced in suitably synchronized fashion.
RTP does not guarantee real-time data transfer nor does not establish or manage the priorities of packets being delivered. For these reasons, RTP packets may be subject to delivery delays or packet losses just like other types of packets. However, these are minor problems for RTP packets even if they do occur. Limited losses of video or audio data still leave the data reproduced more or less satisfactorily; the receiver terminal can proceed with reproduction using only the packets received during a predetermined time period.
Delayed packets or error-carrying packets are discarded by the receiver terminal. That means high-quality data delivered by the sender server may not be reproduced with sufficiently high quality by the receiver terminal. Particularly, if there are at least 10−5 errors in a wired transmission segment or at least 10−3 errors in a wireless transmission segment, reliability remains unacceptably low as long as RTP is applied unmodified.
The problem above has been bypassed by resorting to a technique called ARQ (Automatic Repeat Request). This is an error correcting method that involves detecting lost packets based on RTP packet sequence numbers in order to implement high-quality data transfer. ARQ applicable to the sender server is executed on the basis of RTCP, RTP, TCP, or other equivalent protocol.
As mentioned above, RTP is a protocol for transferring data in real time and has no provisions for reporting or controlling communication status. If used alone, RTP has no arrangements for controlling congestion in keeping with network status or for transferring data by taking into account the performance level of a receiver terminal. Thus RTP is employed in combination with RTCP (Real Time Control Protocol) for exchanging RTP-based information.
Under RTCP, a receiver report (RR) is sent from the receiver terminal to the sender server at predetermined time intervals and so is a sender report (SR) from the sender server to the receiver terminal. These reports allow the sender server and the receiver terminal to conduct a dynamic data transfer reflecting network status or in keeping with the status of the receiver terminal. That is, RTCP is always paired with RTP to supplement the latter functionally.
FIG. 2 is a schematic view depicting a typical structure of a receiver report under RTCP. This report constitutes information that is sent periodically from the receiver terminal to the sender server. The RTCP receiver report is further multicast by the receiver terminal. As shown in FIG. 2, the receiver report includes a header and at least one receiver report block (the example in FIG. 2 has a receiver report block 1, a receiver report block 2, etc.).
The header is made up of version information that indicates the version of RTCP, padding composed of bits for adjusting the packet size, a counter that indicates the number of senders involved in real-time transfer, a packet type, a message length, and a synchronizing source identifier of the sender (i.e., the receiver terminal transmitting this receiver report).
A receiver report block 1 constitutes information created by the receiver terminal based on a packet received from a sender a1 (i.e., sender server a1). The block 1 includes a synchronizing source identifier that identifies the sender a1 (sender server a1) having sent the packet; as well as a packet loss rate, a cumulative lost packet count, a maximum received sequence number, an inter-packet jitter, a latest sender report time, and a sender report elapsed time during transfer from the sender server a1 to the receiver terminal.
Similarly, a receiver report block 2 is constituted by a synchronizing source identifier that identifies a sender a2 (sender server a2) having sent the packet; as well as a packet loss rate, a cumulative lost packet count, a maximum received sequence number, an inter-packet jitter, a latest sender report time, and a sender report elapsed time during transfer from the sender server a2 to the receiver terminal.
There are as many receiver report blocks attached to the receiver report as the number of packets (i.e., value on the header counter) received from each sender (each sender server) from the time the receiver terminal sent the preceding receiver report until this receiver report is transmitted.
FIG. 3 is a schematic view illustrating a typical structure of a sender report under RTCP. This report constitutes information that is sent periodically from the sender server to the receiver terminal. The RTCP sender report is also multicast by the sender server. As shown in FIG. 3, the sender report includes a header, transmission information about transmitted data, and at least one receiver report block (the example in FIG. 3 has a receiver report block 1, a receiver report block 2, etc.).
As with the receiver report in FIG. 2, the header of the sender report is made up of version information, padding, a counter, a packet type, a message length, and a synchronizing source identifier of the sender (i.e., the sender server sending this sender report).
The transmission information is made up of an NTP (Network Time Protocol) time stamp that indicates the time at which this sender report was transmitted, an RTP time stamp corresponding to the NTP time stamp, and the number of packets and that of bytes transmitted from the time the sender server sent the preceding sender report until this sender report is transmitted. The NTP and RTP time stamps allow a plurality of packets to synchronize with a common time base (NTP time base in this case).
The receiver report block 1 constitutes information in the receiver report received from a sender b1 (receiver terminal b1). As such, the block 1 includes a synchronizing source identifier that identifies the sender b1 (receiver terminal b1) having sent the receiver report; as well as a packet loss rate, a cumulative lost packet count, a maximum received sequence number, an inter-packet jitter, a latest sender report time, and a sender report elapsed time during transfer from the sender server to the receiver terminal b1.
Likewise, a receiver report block 2 is constituted by a synchronizing source identifier that identifies a sender b2 (receiver terminal b2) having sent the receiver report; as well as a packet loss rate, a cumulative lost packet count, a maximum received sequence number, an inter-packet jitter, a latest sender report time, and a sender report elapsed time during transfer from the sender server to the receiver terminal b2.
There are as many receiver report blocks attached to the sender report as the number of receiver reports (i.e., value on the header counter) received from the receiver terminal from the time the sender server sent the preceding sender report until this sender report is transmitted.
The exchanges of sender and receiver reports described above permit the sender server to grasp the network status during transfer from the server to the receiver terminal. Knowing the network status allows the sender server to take QoS (Quality of Service) measures such as suitably controlling the rate of data being transferred or multiplexing packets when they are transmitted, as well as to take countermeasures against errors.
However, as discussed above, the packet loss rate and cumulative lost packet count contained in the receiver and sender reports constitute data applicable only to the transfer from the sender server to the receiver terminal; the data helps grasp what is taking place over the network during data transfer in the downward direction from the sender server to the receiver terminal, but not vice versa.
Whereas the repeat request (i.e., the above-mentioned ARQ) is executed depending on the network status during transfer in the upward direction from the receiver terminal to the sender server, the repeat request is often difficult to carry out efficiently. That is primarily due to the conventional inability to know the network status in the upward transfer direction.
One conceivable solution to the problem above involves setting up a second network constituting a feedback system in the upward direction from the receiver terminal to the sender server, independently of the network for transfer in the downward direction from the sender server to the receiver terminal, the second network being used to determine the upward-direction network status. This setup, however, entails considerable discrepancies in network status between the two networks, requiring a complicated network status reporting system for addressing both upward and downward data transfer activities.